이 장에서는 다음과 같은 내용을 다룬다.

  • 좋은 이름 짓기에 대한 여러 가지 관점의 비교
  • 이름과 인지 과정 간의 관계 파악
  • 다양한 명명법의 효과
  • 잘못된 이름이 버그 및 오류에 미치는 영향
  • 변수 이름을 구조화하여 이해도를 극대화하는 방법

서론

  • 8장부터는 코드를 작성하는 과정을 살펴본다.
  • 좋은 이름을 사용하면 LTM을 활성화하여 코드 도메인에 대해 이미 알고 있는 관련 정보를 찾을 수 있다.
    • 반면, 나쁜 이름은 코드에 대한 잘못된 추측을 하게 하고 오개념을 유발할 수 있다.
  • 작업 기억의 용량을 초과하지 않도록 쉬운 이름을 선택하는 것이 인지적 관점에서 타당하다.

8.1 이름이 중요한 이유

8.1.1 명명이 중요한 이유

  • 이름은 코드베이스의 상단 부분을 차지한다.
    • 200만 줄의 코드로 구성된 이클립스 소스 코드에서 토큰의 33%, 문자의 72%가 식별자에 해당된다.
  • 코드 리뷰 시 이름의 역할
    • 코드 리뷰 4건 중 1건이 명칭과 관련한 언급을 포함했으며, 식별자 이름에 대한 언급은 9%를 차지하는 것으로 나타났다.
  • 이름은 문서화의 가장 쉬운 형태
    • 가장 많이 읽는 ‘문서’는 코드 내의 주석문과 이름이다.
  • 이름이 표식 역할을 할 수 있음
    • 변수 이름은 주석문 외에도 코드를 이해하는 데 도움이 되는 중요한 표식이다.

8.1.2 명명에 대한 다양한 관점

  • 좋은 이름은 문법적으로 정의할 수 있다.
    • 코드에 불필요한 정보가 외부 인지 부하를 유발하고 코드를 이해하는 데 방해가 될 수 있기 때문에 문법 규칙을 갖는 것이 합리적이다.
    • 많은 프로그래밍 언어에는 변수 이름의 형식을 지정하는 규약이 있다.
  • 이름은 코드베이스 내에서 일관성이 있어야 한다.
    • 코드 베이스전반에 걸쳐 유사한 객체에 동일한 단어를 사용하면 뇌가 LTM에 저장된 관련 정보를 더 쉽게 찾을 수 있다.
  • 이름이 문법적으로 명확한가? 다어들로 이루어져 있는가? 코드베이스 전체에 걸쳐 일관성을 갖는가?

버틀러의 명명 규약 목록

  • 비정상적인 대문자 사용: 식별자는 대문자를 올바르게 사용해야 한다.
  • 비정상적인 대문자 사용: 식별자는 대문자를 올바르게 사용해야 한다.
  • 연속된 두 개의 밑줄: 식별자는 연속된 여러 개의 밑줄을 가져서는 안 된다.
  • 사전 등재 단어: 식별자는 단어로 만들어야 하고 약어는 원래의 명칭보다 더 자주 사용될 경우에만 사용해야 한다.
  • 단어의 수: 식별자에 사용되는 단어는 두 개에서 네 개 사이여야 한다.
  • 너무 많은 단어: 식별자에 사용되는 단어는 네 개를 초과하면 안 된다.
  • 짧은 이름: 식별자의 길이는 c, d, e, g, i, in, inOut, j, k, m, o, out, t, x, y, z를 제외하고 8글자보다 작으면 안 된다.
  • 열거형 식별자 선언 순서: 분명한 이유가 없다면, 열거형은 알파벳 순서로 선언되어야 한다.
  • 외부 밑줄: 식별자는 밑줄로 시작하거나 끝나서는 안 된다.
  • 식별자 인코딩: 헝가리안 표기법 등으로 식별자 이름에 타입 정보를 나타내면 안 된다.
  • 긴 이름: 긴 식별자 이름은  가능한 한 피해야 한다.
  • 명명법 규약 이상: 식별자는 대문자와 소문자를 표준적이지 않은 방법으로 섞어서 사용하면 안 된다.
  • 숫자를 나타내는 식별자 이름: 식별자는 숫자만을 나타내는 단어나 수를 사용하면 안 된다.
  • 시스템 헝가리 표기법의 사용을 암묵적으로 금지한다.

8.1.3 초기 명명 관행은 지속적인 영향을 미친다

  • 최신 코드는 명명 지침을 더 잘 따른다.
  • 동일한 코드베이스 내에서 명명 관행은 일정하게 유지된다.
  • 명명 관행 면에서 작은 코드베이스와 큰 코드베이스 사이에 차이는 없다.

정리

  • 연구자들도 좋은 이름이 무엇인지에 대한 의견이 다르기 때문에 코드를 읽는 사람에 따라 좋은 이름도 달라진다.
  • 버틀러: 문법적으로 유사한 이름
    • 문법적 지침을 따르면 올바른 이름을 지을 수 있다.
  • 알라마니: 코드 베이스 내에서의 일관성
    • 코드베이스는 주도적이어야 하며, 나쁘더라도 일관적인 편이 그 반대의 경우보다는 낫다.

8.2 명명의 인지적 측면

8.2.1 형식이 있는 이름은 STM을 돕는다

  • 버틀러: 문법적으로 유사한 이름
    • 이름을 처리할 때 인지 부하가 낮음
    • 식별자 이름에 들어갈 수 있는 단어의 숫자를 4개로 제한한 것은 다소 무작위적으로 보이지만, 이 제한은 현재 작업 기억 공간의 최대 크기로 추정되는 2~6개와도 맞아 떨어진다.
  • 알라마니: 코드 베이스 내에서의 일관성
    • 청킹을 지원

8.2.2 명확한 이름이 LTM에 도움이 된다

  • 이름이 체계적일수록 변수명의 각 부분을 식별하기 쉽다.
  • 변수 이름 또는 클래스에 올바른 도메인 개념을 사용하면 코드의 독자가 LTM에서 관련 정보를 찾는 데 도움이 될 수 있다.

8.2.3 변수 이름은 이해에 도움이 되는 다양한 유형의 정보를 포함할 수 있다.

  • 코드의 도메인에 대해 생각할 때 이름이 도움이 된다.
  • 프로그래밍에 대해 생각할 때 이름이 도움이 된다.
  • 경우에 따라 변수에 LTM이 이미 알고 있는 규칙에 대한 정보가 포함될 수도 있다.

고민 요소

  • 이름의 형식이 STM을 지원하는가? 이름의 각 부분을 더 명확하게 해서 이름을 개선할 수 있겠는가?
  • LTM이 도메인을 이해하는 데 도움이 되는가? 이름을 더 명확하게 개선할 수 있는가?
  • LTM이 사용하는 프로그래밍 개념을 이해하는 데  도움이 되는가? 이름을 더 명확하게 개선할 수 있는가?
  • 이름이 프로그래밍 규약에 기초해서 만들어져 LTM이 이해하는데 도움이 되는가?

8.2.4 이름의 품질 평가 시기

  • 코딩 이외의 시간에 이름의 품질을 숙고하는 것이 바람직하다.
  • 코드 리뷰는 식별자 이름의 품질을 검토하기에 좋은 기회다.
  • 코드에 대해 아무것도 모르는 상태에서, 이름이 무엇을 의미하는지 명확한가? 예를 들어  이 이름이 구성하는 단어의 의미를 알겠는가?
  • 이름이 모호하거나 불명확한가?
  • 혼란을 줄 수 있는 약어를 사용하는가?
  • 어떤 이름들이 서로 비슷한가? 이 이름들은 서로 비슷한 것들을 가리키는가?

8.3 어떤 종류의 이름이 더 이해하기 쉬운가

8.3.1 축약할 것인가, 하지 않을 것인가?

  • 식별자가 단어인 프로그램을 읽을 때는 글자나 약어에 비해 분당 19% 더 많은 결함을 발견했다. 문자와 약어로 된 프로그램에서는 속도 차이가 없었다.
  • 변수 이름을 기억하기 어렵게 만드는 것은 길이 자체가 아니라 이름에 포함된 음절의 수이다.
  • 코드를 이해하기 쉽게 찾기 위해서라면 명확한 의미의 단어를 사용해는 반면, 기억을 잘하기 위해서라면 간결한 약자를 사용해야 한다. 좋은 변수 이름을 명명하기 위해서는 이 둘 사이의 주의 깊은 균형이 필요하다.
  • 식별자를 접두사 또는 접미사로 묶는 명명 규칙을 사용할 때 주의해야 한다.

8.3.2 스네이크 케이스냐, 캐멀 케이스냐?

  • 캐멀 케이스가 프로그래머와 비프로그래머 모두에게서 더 높은 정확도를 가진다.
  • 답을 선택하는 데 들어간 시간은 더 걸린다.
  • 새로 명명 규약을 결정할 수 있는 상황이라면 캐멀 케이스를 선택하면 된다.

8.4 이름이 버그에 미치는 영향

8.4.1 나쁜 이름을 가진 코드에 버그가 더 많다

  • 잘못된 명명 방식은 단지 읽고 이해하고 유지 보수하기 어려운 코드가 아니라 잘못된 코드일 가능성이 높다.
  • 코드베이스를 검사하여 잘못된 이름이 발생하는 위치를 찾아내는 일은 코드를 개선하고 버그 발생 가능성이 있는 위치를 찾는 데 도움 될 수 있다.

8.5 더 나은 이름을 선택하는 방법

8.5.1 이름 틀

  • 이름 틀은 변수 이름의 요소가 일반적으로 결합되는 패턴이다.
  • 인지 부하 측면에서 관련된 개념을 변수 이름 내에서 그리고 변수 이름 내 다른 위치에서 찾는 것은 불필요한 외부 인지 부하를 유발한다.
  • 변수 이름이 비슷한 경우 동일환 이름 틀을 사용하면 LTM이 관련 정보를 더 쉽게 찾을 수 있다.
  • 유사한 이름 틀을 사용하면 작업 기억 공간과 LTM에 큰 도움이 되기 때문에 각 코드베이스에서 사용할 수 있는 여러 가지 이름 틀을 미리 정해놓는 것이 좋다.

8.5.2 더 나은 변수명에 대한 페이텔슨의 3단계 모델

  1. 이름에 포함할 개념을 선택한다.
  • 첫 번째 단계에서는 이름을 통해 나타낼 개념을 선택하는데, 개념은 도메인별로 아주 많이 다르며 어떤 차원을 포함할 것인지 결정하는 것이 가장 중요할 수도 있다.
  • 이름을 선택할 때 고려해야 할 주요 사항은 이름의 의도이다.
  1. 각 개념을 나타낼 단어를 선택한다.
  • 각 개념을 나타낼 단어를 선택하는 것이 좋다.
  1. 이 단어들을 사용하여 이름을 구성한다.
  • 선택한 단어를 사용하여 이름을 구성하는 것으로, 이름 지정 틀 중 하나를 선택하는 것에 해당한다.
  • 변수를 정의하는 자연어에 맞춰 이름 틀을 사용하라.
  • 변수 이름을 보다 자연스럽게 만드는 것은 전치사를 추가하는 것이다.

요약

  • 캐멀 케이스 같은 문법 규칙부터 코드베이스 내의 일관성까지, 좋은 이름에 대한 다양한 관점이 있다.
  • 다른 차이가 없다면 스네이키 케이스로 작성된 변수보다 캐멀 케이스 변수가 기억하기 쉽다. 하지만 사람들은 스네이크 케이스를 더 빨리 식별한다.
  • 잘못된 이름이 있는 코드에서 버그가 발생할 가능성이 높다. 다만 이 둘 사이에 반드시 인과관계가 있는 것은 아니다.
  • 다양한 형식의 변수명을 만드는 데 사용할 수 있는 이름 틀이 많이 있으므로, 틀의 수를 줄이면 코드를 이해하는 데 도움이 된다.
  • 페이텡슨의 3단계 모델(이름에 사용할 개념, 해당 개념에 사용할 단어, 결합 방법)을 적용하면 고품질의 이름을 만들 수 있다.

참고